User space is a mode of operation for user applications, as opposed to kernel space, which is a supervisor mode of operation that has advanced functionalities having all rights, particularly the one for accessing all the resources of a microprocessor. Manipulation of resources is nevertheless made possible in user space by what are known as API (“Application Programming Interface”) functionalities, which themselves rely on the use of peripheral pilots. The development of a solution in user space makes possible and facilitates development of schedulers with time constraints in relation to direct integration into the kernel of the operating system, which is made very difficult by its complexity. Another advantage is that it brings increased stability because an execution error in user space does not have serious consequences for the integrity of the rest of the system.
In order to perform scheduling in user space, the method of the invention relies particularly on the mechanisms defined by the POSIX (“Portable Operating System Interface-X”, the “X” expressing the Unix heritage) standard and its extension POSIX.1c, and notably on the POSIX task structure, the POSIX threads (“pthreads”) and the POSIX task management APIs. It should be remembered that a process is a program instance that is being executed, a “task” is a division of a process and a “thread” is the accomplishment of a task under Linux by means of the POSIX APIs; a thread or task cannot exist without a process, but there may be a plurality of threads or tasks per process. In this regard, reference may be made to the work by Robert Love “LINUX system programming”, O'Reilly, 2007.
Linux is a system in which the management of time is called “shared time”, as opposed to “realtime” management. In this type of management, several factors linked to the operation of the system, such as resource sharing, input/output management, interrupts, influence on virtual memory etc., give rise to temporal uncertainties about the execution times of the tasks. Therefore, it is not possible to guarantee a “hard” realtime solution, that is to say one in which the execution of each task is accomplished within strict and inviolable time limits. The realization of the proposed scheduler is nevertheless suitable for what are known as “soft” realtime systems, or systems “with deadline constraints”, which accept variations in the processing of the data of the order of no more than one second. This is the case with a large number of realtime applications, for example multimedia applications.
As it is not natively a realtime system, several technical solutions are, however, possible for making the Linux kernel compatible with realtime constraints. The most common solution involves associating therewith an auxiliary realtime kernel having a genuine realtime scheduler (RT Linux, RTAI, XENOMAI). This auxiliary realtime kernel has priority and processes realtime tasks directly. Other (non-realtime) tasks are delegated to the standard Linux kernel, which is considered to be a background task (or job) with lower priority. However, the development of a specific scheduler integrated into the kernel is very difficult because it requires in-depth knowledge of the kernel and involves heavy kernel development, with all the complexity and instability that that brings. Moreover, realtime Linux extensions are supported by a smaller number of platforms. The proposed solution allows implementation in user space that is therefore simpler, more stable and can be applied to any platform supporting a standard Linux kernel. This approach does not allow hard realtime constraints to be guaranteed, but considerably simplifies the development of a scheduler while being suitable for soft realtime applications (the great majority of applications).